home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
ftp.cs.arizona.edu
/
ftp.cs.arizona.edu.tar
/
ftp.cs.arizona.edu
/
icon
/
newsgrp
/
group93a.txt
/
000043_icon-group-sender _Sun Jan 24 12:19:12 1993.msg
< prev
next >
Wrap
Internet Message Format
|
1993-04-21
|
2KB
Received: by cheltenham.cs.arizona.edu; Sun, 24 Jan 1993 10:48:39 MST
Date: Sun, 24 Jan 93 12:19:12 EST
From: Paul_Abrahams@MTS.cc.Wayne.edu
To: icon-group@cs.arizona.edu
Message-Id: <556329@MTS.cc.Wayne.edu>
Subject: Rremoving entab/detab from Icon
Status: R
Errors-To: icon-group-errors@cs.arizona.edu
I may have used entab/detab occasionally, but I don't remember using
them. Moving them to the library would make sense, however, only if
semantic equivalence could be guaranteed, i.e., one could always repair a
program using entab/detab by adding appropriate library loads. Lacking
such equivalence, it would be a mistake to remove them from the language.
Incompatible change is dangerous--you never know who will get stung, or
with what effect.
That principle, of course, can be carried to extremes. While deleting
merely useless facilities isn't worth the hazard, deleting facilities
that interfere with sensible programming often is justified. Some of the
changes from K&R C to ANSI C probably fall into that category.
The best example I can think of of a terrible language facility that is
almost impossible to remove is the COMMON/EQUIVALENCE stuff in Fortran.
I haven't followed developments in the Fortran world for a long time, but
I know that people have been most hesitant to tinker with COMMON/
EQUIVALENCE because of how the changes might impact programs in use in
critical applications such as aeronautical engineering and nuclear power
plant control.